Method for securing software updates

ABSTRACT

This invention proposes a method for securing updating software in a plurality of decoders based on the generation of a signature by means of a private asymmetrical key. The updating of a decoder is carried out by downloading, from a managing center, a data block including a patch and its signature, said block is stored in a RAM. The signature is decrypted with a current public key from a list contained in a first non-volatile memory of the decoder, then verified and in the case of correspondence, a command leads the installation of the patch in a second non-volatile Flash memory and the deactivation of the current key. The aim of this invention is to considerably reduce the impact of the discovery of a private key by mean of a systematic analysis of the working of the decoder software, or to notably increase the time and the means necessary for the process used to determine said private key.

BACKGROUND OF THE INVENTION

[0001] This invention concerns a method for securing processing softwareupdates ensuring the working of various systems. In particular, themethod of this invention uses a numerical signature mechanism with aprivate key of an asymmetrical encryption algorithm.

[0002] A system is defined here as an apparatus or a set of apparatuseswhich functioning depends on one or several software programs stored ina non-volatile memory or on a hard disk. When the functionality of thesystem must be improved or completed in order to adapt to the increasingdemands of the user, it is often necessary to only update the relatedsoftware without therefore having to change all the material making upthe system.

[0003] In general, updating a given software is carried out by replacingsoftware files already installed or by adding new files for completingthose which are already stored. The assembly thus constitutes a newversion of the software previously installed in the system that benefitsin this way from the desired improvements.

[0004] Various apparatuses such as computers and their peripheralequipment, vending machines, fixed and mobile phones, Pay-TV decoders,etc. are controlled by software programs adapted to their configurationand to the functions of specific components.

[0005] For example, in a Pay-TV decoder (Set Top Box), processingsoftware controls peripheral equipment such as a hard disk, a chip cardreader, data reception interfaces and memories. In order to introducechanges either at the configuration level or at functionality level, itis sometimes necessary to replace the existing software or to introduceimprovements to that which is already installed in the decoder. Thistype of improvement takes place by means of software portions, calledupdates or patches, provided by the operator's managing center, to whicha certain number of users are subscribed. These updates are regularlyprovided by the managing center and are downloaded into the decoders ofeach subscriber possessing the necessary rights.

[0006] The document WO98/43431 describes a method for downloadingapplications into a receiver/decoder. The application software isdivided into modules and the downloading of the modules is preceded by asearch of a directory module at a determined local address. The modulesare signed and the directory module is signed and encrypted in such away that a single encryption is applied to all the modules forming theapplication. Several public encryption keys are stored in a read onlymemory (ROM) of the receiver/decoder. The applications can thus becreated by means of different sources without the knowledge of each oftheir private keys being required. A directory signature can beconcealed in a variable position in an arbitrary data block of thedirectory module. An application to be downloaded can be verified bymaking a comparison with an application validation bitmap stored in thereceiver/decoder.

[0007] The document WO01/35670 describes an information authenticationmethod transmitted to a Pay-TV decoder. A software object and aseparated data structure containing the authorization data arenumerically signed with a global signature that covers both objects.These objects are transmitted separately to the decoder. Once thedecoder has received these objects, the signature is verified. Ingeneral, decoder users have a subscription contract with an operatorthat guarantees a regular maintenance service for the software installedin the decoder. In order to limit misuse such as unauthorized copies andthe introduction of foreign software components, it is essential tosecure the software updating of the decoder. A known method consists inusing a digest coded with an asymmetrical encryption algorithm key ofthe RSA type. The updating software is provided on-line with a digestobtained by means of a unidirectional hash function. This digest is madeup of a single image representing the whole updating and it is assumedthat two identical digests never exist on two identical assemblies withdifferent data. This digest is encrypted thanks to an operator's privatekey associated to a group of subscribers, which constitutes a signaturespecific to this group. The software accompanied by this signature isloaded in a RAM (Random Access Memory) of the decoder. A programbelonging to the decoder software calculates a digest of the softwarestored in the RAM with the hash function. The received signature isdecrypted with a public key contained in the decoder and is thencompared to the software digest calculated previously. If the decryptedsignature corresponds to the digest obtained by means of the hashfunction, the signature accompanying the update stored in the RAM willbe considered as valid. The updating software will be installed in thenon-volatile memory of the decoder (Flash memory).

[0008] The securing process is thus carried out by means of theverification of the signature with a public key in the decoder whichcorresponds to the operator's private key.

[0009] The public key present in the decoder as well as the programallowing signature verification must be fixed. The authenticity of thesignature is guaranteed owing to the fact that the private key dependson the decoder's public key. The signature cannot be reproduced becausethe private key is only known by a given operator. Furthermore, the samesignature is useless for various different updates since it is afunction of a well-defined updating. A signed updating software whosecontent is modified in the RAM will produce another digest which cannotthus be validated by the signature decrypted by the public key. In fact,the digest obtained after the hashing of the updating software at thelevel of the decoder is different to that obtained after decrypting thesignature.

[0010] However, this securing method includes a weak point consisting inthe operator's private key itself. In fact, when said key is discoveredby a third party, it can sign any software and lead to abusivemodifications of the system.

[0011] This discovery can be made by means of iteration on the publickey that the third party has extracted from the decoder until thecorrect pair of keys are discovered. The counter-measure, that consistsin modifying the behavior of the decoder software so that it refuses thesignatures generated with the discovered key, is insufficient sincethese modifications can be avoided by the third party by using suitableprograms.

[0012] The aim of this invention is to considerably reduce the impact ofthe discovery of a private key by mean of a systematic analysis of theworking of the decoder software, or to notably increase the time and themeans necessary for the process used to determine said private key.

[0013] The aim is achieved by means of a securing method for dataupdating in a plurality of apparatuses, each apparatus receiving theupdates from a managing center, these updates including data calledpatch accompanied by a control block encrypted by a private asymmetricalkey taken from a list of keys contained in the managing center,characterized by the following steps:

[0014] selection by the apparatus of a current key from a list of publickeys,

[0015] reception of the updating patch and storage in the memory,

[0016] reception of the encrypted control block,

[0017] decryption of said block by the current public key,

[0018] verification that the decrypted control block corresponds to saidpatch,

[0019] installation of the patch received,

[0020] deactivation of the current key and selection of the next key onthe list.

[0021] The data of an update is transmitted by the managing center inthe form of a patch and a control block including a signature made up bythe digest of the patch encrypted with a private key from the managingcenter. The decoder stores this data in the RAM memory for processing. Apublic key, associated to this private key, called the current key, isselected from a list stored in a first non-volatile memory in order todecrypt the patch signature. In the case that decryption andverification are successful, a command is carried out leading to theinstallation of the patch in a second non-volatile memory (Flash) of thedecoder. The current key used in this way is deactivated on the list,which makes the following key available for the next update.

[0022] When the verification of the signature and the decryption of adecoder update is carried out with a public key from the list, said keyis deleted and cannot be used for further updates. Thus, a new key isused for each update and is then eliminated from the list. The publickey from the list as well as the program serving to verify thesignatures must be non-modifiable. Only the list can be modified(elimination of used keys) with the verification program.

[0023] The above-described method allows a considerable reduction of thepossibilities of decoder modifications by a third party havingdiscovered a private key. Since a key can only be used once, the thirdparty will only carry out a single modification. Consequently, amodification of decoder behavior in order to protect it from piracy ismore effective since the third party, no longer in possession of a validprivate key, is unable to access the apparatus.

[0024] Due to the fact that the number of private keys is larger, athird party must therefore systematically activate all the keys to avoidto be blocked at the update corresponding to the discovered key. It isnecessary to know that the development of the decoders' software is fastand considering that if one of the keys is discovered the followingupdates will fill the security gap that the third party would have beenable to introduce. If this third party is able to block all subsequentupdates, the functionalities of the decoder will rapidly become obsoleteand therefore without any important prejudice to the operator.

[0025] The use of asymmetric keys is important in this context since theextraction of public keys from a decoder does not allow theimplementation of an acceptable update because said update must besigned by the operator's private key. It is common to place the privatekeys in the secured part (the operator) and the public keys in thepublic domain part (the decoder). Nevertheless, it is possible to invertthe keys without damaging the functioning of the present invention.

[0026] A first embodiment of the invention proposes the use of publickeys taken from the list according to a pre-determined order. Therefore,each key is taken from the list as soon as the previous key has beenused.

[0027] The invention will be better understood thanks to the followingdetailed description with reference to the attached figures serving as anon-limitative example, namely:

[0028]FIG. 1 represents the progress of an updating process of a decoderfrom a version N to a version N+1.

[0029]FIG. 2 shows an updating from a version N to a version R In theexample disclosed in FIG. 1, an initial version decoder is updated tothe version 1 with a patch P1. This patch P1 is transmitted with itssignature (H(P1))PK1 by the operator's managing center towards thedecoder. The updating process begins by the loading of the patch P1 intothe RAM of the decoder.

[0030] The signature (H(P1))PK1 is obtained by the encryption of thedigest H(P1) of the patch P1 with the private key PK1 of the operator,this operation being carried out in the managing center. This digest iscalculated by the operator from the patch P1 with a unidirectional hashtype function H.

[0031] The decoder software decrypts the received signature (H(P1))PK1with a public key K1 in order to obtain the digest of the patch H(P1)1.Simultaneously, this same software calculates the digest H(P1)2 of thepatch P1 stored in the RAM. The first digest issued from the decryptionof the signature H(P1)1 and the second H(P1)2 resulting from thecalculation by means of the hash function H are compared. If the twovalues correspond, the patch P1 is installed in the decoder'snon-volatile Flash memory FH in order to carry out the updating of thedecoder software. The public key K1 used to decrypt the signature isdeleted from the list.

[0032] A second update of version 1 to version 2 transmitted by themanaging center in the form of a new patch P2 accompanied by itssignature (H(P2))PK2 passes through the same downloading andverification process. A new public key K2 taken from the list will thenbe used by the decoder. All the following transmitted updates areverified in the same way using each time a new public key taken from thelist. The previous updating keys are neutralized either by deletion orby a suitable marking.

[0033] By applying this process, a software update from version 1 toversion N is carried out in N−1 steps. The managing center will transmitN−1 patches with corresponding N−1 signatures each encrypted by aprivate key specific for each version. The installation of the differentpatches thus leads to the neutralization of N−1 public keys from thelist.

[0034] The list of public keys can be stored, for example, in anon-volatile memory of the type EEPROM (Electrically ErasableProgrammable Read-Only Memory). After each use of a key during anupdate, said key is definitively deleted from the EEPROM authorizing theaccess to the following key for the next update.

[0035] According to another embodiment, the list of public keys is notaltered by the deletion or marking of a key. After each installation ofa software version in the non-volatile Flash memory, a counter isincremented or a pointer moves to indicate the position of the key to beselected from the list during the next update. Therefore, at eachupdate, only the key which will serve to decrypt the signature of thepatch is designated, the previous keys no longer being available forselection because the counter or the pointer can only progress in onedirection, that of increasing positions.

[0036] According to a variant, the patch can be encrypted by the privatekey of the operator. A supplementary decryption step is thus added tothe above-described process. The patch P received and loaded into theRAM can be decrypted with the public key before the calculation with thehash function H of the digest serving as signature verification. Thecalculation of the digest can also be carried out on the patches in itsencrypted form.

[0037] Update installation by a third party is made more difficult bythe fact that each version change requires knowledge of the current key.The latter changes at each update, which obliges the third party to knowall the keys in order to follow the different updates.

[0038] The previously described process can occur a problem when thedecoder has remained out of service during a time in which severalupdates should have been carried out. The passing of an old softwareversion to a new version whose number is not consecutive to that of theprevious version is carried out sequentially in several successivesteps. The said steps use different public keys taken from the list oneafter the other and in a consecutive order. It is reminded that thepatch itself does not contain a command that allows the selection of akey other than the current key. If it is the case, a third party coulduse this command to force the use of a key known to said third party.

[0039]FIG. 2 shows the case of the passing from a software version N toa version R where the difference R-N between the new version and theprevious version is greater than one. The following example refers to acase where N=2 and R=5.

[0040] A decoder with version 2 software cannot directly decrypt thesignature (H(P))PK5 of the new version 5 because the key available inthe list of public keys is that of the version immediately higher,namely the key K3. For the installation of the new version 5, thedecoder must be able to gain access to the key corresponding to thisversion, that is to say the key K5.

[0041] The solution consists in transmitting a data flow containing thepatch P for updating the software of the decoder to version 5 signedwith the key PK5 to which a plurality of messages M1, M2, M3, M4 areadded, each encrypted with a private key PK1, PK2, PK3, PK4 taken fromthe key list. The RAM memory stores these messages as well as the patchP with its signature (H(P))PK5. The version of the decoder being 2, theupdating key of version 1 to 2 is already deactivated by the firstupdate. The message M1 is then ignored because the key K1, that servesto decrypt it, is no longer available.

[0042] The following messages M2, M3 and M4 are used to consecutivelydeactivate the public keys K2, K3, and K4 that correspond to eachintermediate version from version 2 to version 4 preceding version 5.Therefore, to install version 5 in the non-volatile Flash memory, eachpublic key K2, K3, and K4 of the list is used then neutralized ordeleted. During the decryption of the message by the correct key, thecontent of this message is recognized and induces the neutralizationoperation of the current key. If the message is not recognized, thismeans that the encryption key of this message is not the current key.

[0043] After the successive and correct decryption of the messages M2,M3, M4, the key K5 necessary for the decryption of the signature of thepatch (H(P))PK5 (and of patch P) becomes the current key. The latterwill also be deleted from the list after the installation of the patchand the key K6 will be present at the head of list for the subsequentupdate of version 5 to version 6.

[0044] This type of flow can thus update an entire group of decodersregardless of their software version thanks to the key change messagesthat accompany the patch. Each decoder disposes of a public key in thelist able to decrypt an update of the current version after theneutralization of the old keys.

[0045] During a decoder software update of version N to a version Rwhere the difference R−N becomes large, for example over 10, it becomestedious for a decoder with version R−1 to systematically decrypt all themessages in order to verify the deactivation orders. This decoder willapply its current key (R-1) to all of these messages to notice that itis unable to interpret its contents.

[0046] A first solution consists in introducing in the message headerindexes in clear that correspond to the numbers of the differentversions. This index only serves to avoid the decryption of messagesthat have been encrypted by a key other than the current key. This indexdoes not select the position of the current key, only the successfuldecryption of a message with said current key induces the advance of oneposition in the keys list.

[0047] According to a second solution, the digest of the updating patchis successively encrypted by all the private keys of the previousupdates. This process obliges the use of each public key on the list,consecutively, to decrypt the signature. In this case of encryption inchain, unlike in the previous case, all the public keys must remainavailable in the EEPROM of the decoder. For example, for an update ofversion 1 to version N, the digest of the patch P is encrypted with aprivate key of version N. The whole set is then encrypted with theprivate key of version N−1, then with the key of version N−2 and so onuntil the version 1. The decryption thus requires the successive use ofpublic keys K1 to KN−1 corresponding to the updates of version 1 toversion N. The interruption of this iterative mechanism is enabled bymeans of the recognition of a suitable mark in the decryption result.

[0048] If one wishes to protect the update data, one method consists inthe use of a session key SK randomly generated by the managing centerfor example. For reasons of operation speed, this key is of asymmetrical type. The managing center encrypts the patch with thesession key SK and composes a data set that includes the session key SKand the digest of the updating patch. This set is encrypted by thecurrent private key of the operator to make up the control block.

[0049] The encrypted patch and the control block are loaded into the RAMmemory of the decoder. The block is decrypted by the current public keyon the list, which provides the patch digest and the session key SK. Thelatter is applied to the patch loaded in the RAM thus allowing itsdecryption. Then, the patch digest is verified and in the case ofcorrespondence the patch is installed in the non-volatile Flash memory.

[0050] The session key can be introduced as a supplementary securingmean in any of the variants described above, for example:

[0051] the simple update of version 1 to version N in several steps,

[0052] the updating of version N to R with a patch and key deactivationmessages.

[0053] In a decoder that has been updated several times, the number ofavailable public keys decreases while the number of deactivated keysincreases with the successful updates. In order to rebuild a list ofkeys to allow future updates, a new public key list can be sent to thedecoder by the managing center. This list can be incorporated into thedata, flow and accompanied by a signature as in the case of an updatingpatch. Said list is stored in the EEPROM and replaces the old listcontaining the deactivated keys.

[0054] According to a variant of the method of the invention, themanaging center and the decoders dispose respectively of a fixed privateand public key list. For each update, the managing center randomlyselects a private key set from those on the list and encrypts the patchdigest successively with each key of the set. The center creates a datablock that includes the encrypted digest (signature) and a series ofnumbers corresponding to the positions of the previously chosen keys.Said series can be transmitted in clear or encrypted with a session key.The decoder receiving said series selects from the list of public keys,according to their position, the keys necessary to decrypt the patchdigest. The list cannot include the same key number more than once andthe length of this list (number of keys used) is known andnon-modifiable. In this variant, the lists of keys remain fixed and arenot altered after a successful patch installation. At each update, a newkey combination taken from the list is used for the patch signature.Therefore, a third party must always dispose of a set of keys in orderto introduce an update into an apparatus, which requires more importantmeans than the means required to determine a single key.

[0055] The update securing process according to the invention isindependent of the transmission mode used between a supplier and a user.In fact, the process can also be applied to patches distributed onCD-ROM, on disks or on any other digital data storage medium.

What is claimed is:
 1. Method for securing updating data from aplurality of apparatuses, each apparatus receiving the updates from amanaging center, these updates including data called patch accompaniedby a control block encrypted by a private asymmetrical key taken from alist of keys included in the managing center, characterized by followingsteps: selection by means of the apparatus of a current key from a listof public keys, reception and storage in the memory of the updatingpatch, reception of the encrypted control block, decryption of saidblock by the current public key, verification that the decrypted controlblock corresponds to said patch, installation of the patch received,deactivation of the current key and selection of the next key in thelist.
 2. Method according to claim 1 wherein the control block includesa signature on the patch data, this signature being the result of a hashfunction.
 3. Method according to claims 1 and 2 wherein the verificationof the block includes the step of establishing the signature on thereceived patch and the comparison with the decrypted signature in thecontrol block.
 4. Method according to claim 1 wherein the control blockincludes a symmetrical session key determined by the managing center,this key being used to encrypt the patch data.
 5. Method according toclaim 1 wherein, for each update, a new public key taken from the listis used by the apparatus.
 6. Method according to claim 1, wherein thepublic key is deleted from the list after being used, said key beinguseless for the next updates.
 7. Method according to claim 1, whereinthe public keys of the list are used sequentially in a predeterminedorder during each update.
 8. Method according to claim 1 wherein thelist of public keys is stored in a non-volatile memory, a key used foran update is definitively deleted from the memory that authorizes theaccess to the next key for the subsequent update.
 9. Method according toclaim 1 wherein, for the updating of the software of an apparatus of acertain version to a new version, with a difference between the newversion and the previous one greater than one, at least one messageencrypted with a private key is added allowing the changing of thecurrent key to the next key in the list, the successful decryption ofsaid message inducing the deactivation of the current key and theselection of the next key.
 10. Method according to claim 9, wherein thenumber of messages corresponds to the number of updates separating theinitial version of the apparatus and the final version of the update.11. Method according to claim 1, wherein an updating installation isfollowed by an increment on a counter or by moving a pointer indicatingthe position of the key to be selected from the list during thesubsequent update, while the list of keys remains unchanged.
 12. Methodaccording to claim 1, wherein the control block is successivelyencrypted by the keys of the previous updates, each key from the listbeing used one after the other to decrypt the signature.
 13. Methodaccording to claim 1, wherein the apparatuses consist of Pay-TVdecoders, an update of a decoder being carried out by downloading, froma managing center, of a patch accompanied by a control block, said blockis stored in a Random Access Memory, and is decrypted with a currentpublic key contained in a first non-volatile memory of the decoder, thenverified and in the case of correspondence, a command leads theinstallation of the patch in a second non-volatile memory and thedeactivation of the current key.
 14. Method according to claim 13,wherein a new list of public keys is transmitted to the decoder, saidlist replaces the list contained in the first memory containing keysdeactivated by previous successful updates.